IBIS Macromodel Task Group Meeting date: 15 September 2020 Members (asterisk for those attending): Achronix Semiconductor * Hansel Dsilva ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: Ambrish Varma Ken Willis * Jared James Google: * Zhiping Yang Intel: * Michael Mirmak * Kinger Cai Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan Todd Bermensolo * Rui Yang Marvell Steve Parker Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the September 01 meeting. Michael moved to approve the minutes. Randy seconded the motion. There were no objections. ------------- New Discussion: Standard Power Integrity Model (SPIM) with Unified PI Target (UPIT): Kinger Cai reviewed this presentation, which was given at the 2020 IEEE EMC+SIPI Symposium IBIS Summit on August 28th, 2020. - The presentation can be found here: https://urldefense.proofpoint.com/v2/url?u=https-3A__ibis.org_summits_aug20&d=DwIGAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=DcQR-qLpQg5lIreuM6-NYECRIAFXt268PRNS5WO043M&m=zQoyurGPNZu5UZFRusr4oBu7YULxaA2oszaJ3DTwXnU&s=sYjhAvmEVqiK5mzz7Hts5GvxOrjBN-9OBe8hHwbQ6Sw&e= - Summit Minutes including discussion of the presentation can be found here: https://urldefense.proofpoint.com/v2/url?u=https-3A__ibis.org_minutes_min2020_m082820.pdf&d=DwIGAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=DcQR-qLpQg5lIreuM6-NYECRIAFXt268PRNS5WO043M&m=zQoyurGPNZu5UZFRusr4oBu7YULxaA2oszaJ3DTwXnU&s=-vvK9t5FkYsIEyd56DdOeqE-Rw63A2zRy7etBdqpKS4&e= Kinger described FastPI as a design methodology targeted for platform (board level) PI design. It is based on the chip vendor providing SPIM and UPIT information to their customers the platform designers. The goal is to provide sufficient information to the platform designers while protecting vendor IP. He noted that SPIM and UPIT have been part of the standard PI collateral Intel provides to system designers for five years. It is similar in concept to IBIS, which was originally developed by Intel for similar purposes for SI designers. Additional details, beyond those discussed at the Summit and captured in the summit minutes, are recorded here. Zhiping noted that the goals of SPIM (slide 5) parallel the original development of IBIS for SI design. Kinger noted that the UPIT makes the process scalable, as different UPITs could be provided, for example, for different cost/performance variants based on the same SPIM. Arpad referred to the IBIS syntax mockup on slide 13. He asked if the goal was to incorporate this new syntax into IBIS or develop a stand-alone specification. Kinger said he didn't have a strong preference. He expected to broadly follow traditional IBIS syntax. However, since there might not be a lot of interaction between this proposal and SI IBIS simulations, it might be easier to create a stand-alone specification. Arpad, however, noted that the example on slide 13 utilized pin lists and other things that are already included in IBIS. This proposal is related to the chip/die and could be folded into IBIS since the power and ground pins already exist in IBIS. Randy agreed that we have the capability to carry some of this information in our package modeling. Walter said the S-parameter portion of the SPIM should work fine with the rail modeling in our package and EMD modeling. Kinger noted that the SPIM model includes additional information. Randy said it would be helpful to see more detail about the stimulus sources and how they're defined, as this might be what we need to work on standardizing and linking into IBIS. Bob and Zhiping also preferred linking the proposal into existing IBIS, and Bob noted that the example on slide 13 implicitly relies on other keywords such as Pin Mapping. Arpad asked if Kinger could review existing IBIS 7.0 interconnect syntax and see how it fit with his proposal. Kinger said he would look into IBIS 7.0 and work with Michael on possible proposals. New Clock-Data Pin relationship BIRD [Clock Pins]: Michael Mirmak briefly reviewed the Clock Pins BIRD draft he had sent to ATM the day before the meeting. It is intended to address DDR issues. He noted that we have BIRD204, which enable data buffers to accept external clocking inputs, and BIRD207, which allows the executable model to be passed the Component and signal_name of the pin it is simulating. Michael said that nothing yet defines the clocking relationship between any two pins. He said we can't really define that relationship at the .ami level, as it's the [Pin List] that typically controls what the user wants to instantiate. He noted that different pins might have different relationships. You might have one buffer pin that uses one clock pin, or you might have 4 pins that use the same clock pin, etc. This clock-data relationship should be defined at the same level as the [Pin List]. The BIRD defines a new keyword [Clock Pins] at [Component] scope. Each entry contains three columns. The first column is the name of a clock Pin, the second is the name of an associated data Pin, and the third column specifies the timing relationship between the two. Valid values for column 3 are: Clock_Skew, Clock_to_Out, or Setup_Hold. Michael noted that he had intentionally not provided exhaustive definitions of the timing relationships. He said that for the time being they are little more than glorified comments. He said his concern was that hashing out the details of the timing relationships will be a lengthy process, and he said it could be the subject of an additional BIRD. Specifying the clock-pin data-pin relationship is an immediate need, and it's important not to have this BIRD delayed while the details of column three are worked out. Randy noted that the term "pin_name" should be used when referring to pin name entries from the [Pin List], to be consistent with other sections. Michael agreed and noted the change. Randy said the meaning of the three proposed values in column three were not clear to him. Fangyi also said that he would prefer to see some more details on the column three values. Michael took an AR to send out a second version incorporating some of the feedback from the meeting and email. - Randy: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Michael to send a second draft of the [Clock Pins] BIRD proposal. ------------- Next meeting: 22 September 2020 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives